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ABSTRACT  (U) 

(U)  Active  Protection  Systems  (APS)  have  been  in  the  design 
and  development  stages  since  the  early  1950s,  but  none  have 
successfully  made  the  transition  from  development  to  integration 
on  a  platform.  A  contributing  factor  of  this  lengthy  development 
period  is  the  lack  of  common  standards,  APS  requirements  or  a 
fielded  system  that  can  be  followed  as  a  template.  Although 
lacking  firm  APS  requirements,  an  APS  should  be  developed  for 
and  tested  in  a  relevant  environment  that  mirrors  the  operational 
environment  of  its  intended  host  vehicle.  Since  APS  is  a  new 
technology,  there  has  been  no  logical  process  to  follow.  The  Tank 
Automotive  Research  Development  and  Engineering  Center 
(TARDEC)  has  developed  an  APS  Compliance  Plan  to  serve  as  a 
developmental  roadmap  and  a  TRL  estimation  tool.  Using  this 
plan  one  may  detennine  specific  tasks  or  tests  necessary  to 
advance  to  a  higher  TRL,  as  well  as  assess  the  risk  involved  with 
transitioning  an  APS  at  its  current  technology  state.  Further, 
TARDEC  will  use  a  configuration  management  process  to  increase 
the  likelihood  of  APS  transition  to  a  program  of  record.  This  paper 
will  introduce  the  TARDEC  APS  Compliance  Plan  and  describe 
how  it  can  be  used  focus  APS  development  and  transition. 
TARDEC  plans  to  assist  development  and  transition  minded 
efforts  with  a  System  Integration  Laboratory  (SIL)  validation 
process  as  well  as  present  the  vision  for  how  the  Compliance  Plan 
will  operate  in  the  future. 
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14.  ABSTRACT 

Active  Protection  Systems  (APS)  have  been  in  the  design  and  development  stages  since  the  early  1950s,  but 
none  have  successfully  made  the  transition  from  development  to  integration  on  a  platform.  A  contributing 
factor  of  this  lengthy  development  period  is  the  lack  of  common  standards,  APS  requirements  or  a  fielded 
system  that  can  be  followed  as  a  template.  Although  lacking  firm  APS  requirements,  an  APS  should  be 
developed  for  and  tested  in  a  relevant  environment  that  mirrors  the  operational  environment  of  its 
intended  host  vehicle.  Since  APS  is  a  new  technology,  there  has  been  no  logical  process  to  follow.  The  Tank 
Automotive  Research  Development  and  Engineering  Center  (TARDEC)  has  developed  an  APS 
Compliance  Plan  to  serve  as  a  developmental  roadmap  and  a  TRL  estimation  tool.  Using  this  plan  one  may 
determine  specific  tasks  or  tests  necessary  to  advance  to  a  higher  TRL,  as  well  as  assess  the  risk  involved 
with  transitioning  an  APS  at  its  current  technology  state.  Further,  TARDEC  will  use  a  configuration 
management  process  to  increase  the  likelihood  of  APS  transition  to  a  program  of  record.  This  paper  will 
introduce  the  TARDEC  APS  Compliance  Plan  and  describe  how  it  can  be  used  focus  APS  development 
and  transition.  TARDEC  plans  to  assist  development  and  transition  minded  efforts  with  a  System 
Integration  Laboratory  (SIL)  validation  process  as  well  as  present  the  vision  for  how  the  Compliance  Plan 
will  operate  in  the  future. 
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(U)  History  of  Active  Protection 

(U)  An  Active  Protection  System  (APS)  is  specifically  designed  to  prevent  direct  fired  threats 
from  acquiring  and/or  destroying  a  target.  An  APS  is  either  a  softkill  or  hardkill  system  based  on 
its  method  of  defeating  a  threat.  The  countermeasure  of  a  softkill  APS  alters  the  electromagnetic 
or  acoustic  signature  of  a  target  which  effectively  alters  the  tracking  and  sensing  capability  of  the 
incoming  threat;  a  hardkill  APS  physically  counterattacks  the  incoming  threat  by  destroying  the 
warhead  in  such  a  way  that  the  intended  effect  on  the  target  is  majorly  impeded — both  defeat 
methods  have  proven  their  effectiveness  for  neutralizing  incoming  threats. 

(U)  Primitive  APS  were  being  developed  in  the  early  1950s,  beginning  with  the  Anny 
Research  Laboratory’s  Dash-Dot  Program  (shown  in  Figure  1)  and  eventually  evolving  into 
more  recent  designs  (Atlas,  TRAPS,  Iron  Curtain,  EPS,  etc.).  All  APS  have  struggled  with  the 
transition  from  their  development  to  the  final  integration  onto  a  platfonn  for  fielding. 
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Figure  1.  (U)  Primitive  Active  Protection  Systems 


(U)  Current  Situation 

(U)  Throughout  the  history  of  APS,  none  have  successfully  transitioned  from  development  to 
integration  on  a  platform  to  be  fielded  by  the  Department  of  Defense  (DoD).  To  date  no  APS 
has  been  proven  to  be  ready  for  fielding  in  regard  to  their  consistent  capability  to  defeat 
incoming  threats  and  to  do  so  in  a  relevant  environment.  The  accepted  maturity  level  for  new 
technologies  to  transition  to  a  PM  for  final  development  and  integration  onto  a  host  platfonn  is 
TRL  6.  The  TRA  Deskbook  defines  a  relevant  environment  as  representative  of  the  full 
spectrum  of  the  intended  operational  environments1.  Since  an  APS  is  intended  to  be  integrated 
to  a  tactical  or  combat  vehicle,  the  implied  relevant  environment  for  any  APS  should  be  that  of 
its  intended  host  vehicle.  For  example,  a  lightweight,  low  cost  APS  developed  to  defeat  Rocket 
Propelled  Grenades  (RPG)  intended  for  transition  on  a  tactical  vehicle,  which  is  a  relatively  light 
weight,  low  cost  platform  and  prey  to  RPGs.  Similarly,  a  more  capable  but  heavier  and  higher 
cost  APS  capable  of  defeating  Anti-Tank  Guided  Missiles  (ATGM)  would  be  intended  for  an 
armored  combat  vehicle.  The  APS  Compliance  Plan  aims  to  function  as  a  link  between 
establishing  TRL  guidelines  for  enabling  technologies  and  a  smooth  transition  to  a  program  of 
record  managed  by  the  TRA  Deskbook. 
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(U)  One  major  reason  the  gap  between  development  and  transition  exists  is  the  discrepancy 
between  the  APS  design  intent  and  the  Program  Manager  requirements.  In  order  to  increase  the 
potential  for  transition,  the  contractor  should  be  concentrating  on  the  relevant  environment  as 
implied  by  the  PM  requirements  for  their  platforms  during  the  early  stages  of  design  and 
development.  Before  a  PM  would  likely  accept  an  APS  for  transition,  it  must  be:  (1)  at  a  TRL  6 
or  higher,  (2)  require  no  major  redesign  activity  and  (3)  be  a  well  understood  system. 

(U)  TRLs  provide  a  common  understanding  of  technology  maturation  and  can  be  used  as  a 
risk  management  tool.  The  APS  Compliance  Plan  concentrates  specifically  on  TRLs  4  through  6 
in  an  effort  to  mature  the  APS  technology  so  it  is  production  ready.  TRL  definitions  are  shown 
in  Figure  2.  PM  offices  generally  do  not  transition  an  APS  if  it  is  below  the  TRL  6  threshold. 
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Figure  2.  (U)  Technology  Readiness  Levels 


(U)  PMs  want  to  mature  existing  technologies  as  opposed  to  developing  new  APS 
technologies.  They  will  look  to  integrate  a  production  ready  APS  that  requires  no  major  redesign 
activity  after  transition.  The  hardware  and  software  should  have  a  locked  configuration  that  is 
specific  to  the  target  platform.  Post  technology  transition,  minimal  research  and  development 
funding  will  exist.  The  PM  cannot  afford  any  major  redesign  setbacks  after  transition,  if  they 
strive  to  meet  program  schedule  and  cost. 


(U)  The  PM  will  aim  to  transition  a  well  understood  system  onto  their  platform.  Performance 
statistics  are  essential.  The  system  should  be  tested  against  live  threats  prior  to  transition  with 
data  supporting  the  claimed  probability  of  defeat  (P Defeat)-  System  vulnerabilities  should  be  well 
understood.  An  acceptable  performance  risk  threshold  will  always  exist;  however,  mitigation 
plans  should  be  in  place  to  improve  any  areas  with  inferior  performance.  A  PM  can  always 
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transition  a  system  with  a  greater  performance  risk,  if  there  is  an  urgent  need  for  additional 
protection.  The  Compliance  Plan  is  not  a  mandated  activity  but  rather  a  risk  assessment  tool  that 
focuses  development. 

(U)  Compliance  Plan  Overview 

(U)  In  an  effort  to  narrow  the  gap  between  APS  development  and  what  a  PM  desires  for 
transition  onto  a  platform,  TARDEC  has  developed  an  APS  Compliance  Plan.  The  primary 
objectives  of  the  Compliance  Plan  are  to: 

(U)  (1)  estimate  the  TRL  of  a  specific  APS  to  a  common  standard; 

(U)  (2)  verify  TRL  compliance  to  Program  Managers  interested  in  APS  transition; 

(U)  (3)  detennine  if  the  APS  is  mature  enough  to  start  a  compliance  effort; 

(U)  (4)  establish  specific  tasks  required  to  achieve  each  TRL  milestone  with  respect  to 

APS  technologies  as  a  function  of  gate  review. 

(U)  It  is  essential  that  the  TRL  of  each  APS  is  evaluated  using  a  common  standard  to  avoid 
discrepancies  between  the  system  capability  and  the  PM  requirements  for  competing 
technologies.  The  Compliance  Plan  will  be  tailored  to  a  particular  APS  with  platform  specific 
requirements  in  mind.  As  a  contractor  is  developing  an  APS  technology,  the  Compliance  Plan 
can  serve  as  a  roadmap  to  ensure  they  are  working  toward  a  transition  ready  system.  All 
contractors  can  utilize  the  same  roadmap,  essentially  leveling  the  playing  field  for  all  APS 
developers. 

(U)  The  PM  needs  a  method  to  verify  that  the  claimed  TRL  of  the  APS  is  an  appropriate 
assessment.  A  PM,  after  receiving  a  proposal  for  transition,  can  turn  to  TARDEC  to  verify  the 
TRL  of  that  particular  APS.  TARDEC  engineers  can  work  collaboratively  with  the  contractors, 
while  utilizing  the  Compliance  Plan,  to  make  an  unbiased  and  accurate  TRL  assessment  of  the 
system.  This  third-party  TRL  assessment  can  (1)  prove  invaluable  for  risk  reduction  and  (2)  hold 
more  weight  with  the  PMs  interested  in  transition. 

(U)  A  significant  DoD  investment  will  be  required  each  time  the  Compliance  Plan  is 
executed.  The  Compliance  Plan  is  a  lengthy  process  that  will  require  funding;  both  PMs  and 
TARDEC  need  to  be  selective  when  determining  whether  an  APS  is  ready  to  apply  for 
Compliance.  Prior  to  starting  a  Compliance  Plan  effort,  TARDEC  must  verify  that  both 
hardware  and  software  configurations  are  locked  as  any  configuration  or  design  change  will  end 
the  effort  and  require  a  new  Compliance  Plan  assessment  in  the  future. 

(U)  As  previously  stated,  each  Compliance  Plan  effort  will  be  APS  specific.  The  tasks  and 
testing  required  for  each  APS  will  be  established  at  the  beginning  of  each  Compliance  Plan 
effort.  Each  APS  will  have  a  tailored  set  of  tasks  and  tests  that,  upon  successful  completion,  will 
put  the  APS  in  the  best  possible  position  for  transition.  The  Compliance  Plan  will  utilize 
TARDEC ’s  new  gate  review  process  called  TARGET  (shown  in  Figure  3)  to  ensure  the  key 
tasks  required  are  aligned  appropriately  with  customer  needs. 
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Figure  3.  (U)  TARDEC  TARGET  Gate  Review  Process 


(U)  The  APS  Compliance  Plan  uses  specific  requirements  to  measure  and  evaluate  the 
technical  maturity  of  APS,  subsystems,  components  and  software  configurations.  The 
Compliance  Plan  concentrates  on  TRL  4  through  6  tasks,  working  from  the  design  intent  of  the 
components/system  (TRL  4),  component  testing  and  validation  (TRL  5)  and  system 
demonstration  in  a  relevant  environment  (TRL  6). 


(U)  Compliance  Plan  Attributes 

(U)  The  Compliance  Plan  is  intended  to  be  a  risk  assessment  tool  for  PMs.  They  detennine 
the  allowable  risk  tolerance  and  can  transition  any  APS  configuration  at  any  time.  The 
Compliance  Plan  is  a  detailed  process  to  determine  technical  maturity  of  an  APS.  Tasks  and 
tests  are  broken  down  to  fundamental  levels  to  ensure  that  the  performance  of  each  component  is 
both  verified  and  validated.  The  Plan  is  a  comprehensive  effort  including  all  government 
activities  required  to  assure  the  APS  works  as  intended  and  that  it  meets  the  transition 
requirements.  It  is  also  a  living  document  that  will  be  customized  for  each  APS  technology 
Compliance  effort  and  configuration  managed  as  well. 

(U)  APS  Compliance  is  not  intended  to  be  a  research  and  development  effort,  rather  the 
validation  of  one.  Prior  to  entering  a  Compliance  Plan  assessment,  the  APS  must  be  both 
software  and  hardware  configuration  locked  and  require  no  major  design  changes.  Upon 
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receiving  APS  Compliance,  the  contractor  is  not  guaranteed  transition  to  a  program  of  record; 
however  it  may  increase  the  possibility  of  one.  The  TRL  assessment  and  conclusions  will  be 
provided  to  the  PM,  who  has  final  decision  authority  for  transition. 

(U)  Program  Structure 

(U)  A  detailed  layout  of  the  APS  Compliance  Program  Structure  is  shown  in  Figure  4.  This 
figure  demonstrates  how  the  APS  Compliance  Plan  will  fit  into  the  TARDEC  TARGET  gate 
review  process  as  well  as  how  it  could  feed  into  an  acquisition  program  of  record.  Generally, 
prior  to  entering  a  Compliance  effort,  the  APS  should  have  received  a  successful  Gate  3  review. 
All  major  design  and  development  stages  should  be  complete  and  both  the  hardware  and 
software  should  be  configuration  locked;  however,  this  is  a  gray  area.  If  the  majority  of  the 
design  process  is  complete,  a  PM  could  request  that  it  enter  a  Compliance  effort  early,  with  a 
greater  risk  for  not  reaching  the  objective  TRL  Compliance  at  the  completion  of  Gate  5. 
Minimal  research  and  development  funding  will  be  available;  it  is  in  the  contractor’s  best  interest 
to  be  as  far  along  in  the  design  process  as  possible  before  starting  a  Compliance  effort. 
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Figure  4.  (U)  APS  Compliance  Plan  Program  Structure 


(U)  This  program  structure  layout  assumes  that  there  are  well  defined  PM  requirements  in  the 
beginning  concept,  feasibility  and  design  phases.  The  requirements  should  be  in  place  after  a 
successful  Gate  1  review,  but  are  subject  to  change  once  the  design  process  has  begun.  These 
changes  may  be  necessary  because  there  will  be  a  better  understanding  of  how  the  APS  will 
operate;  this  could  lead  to  unforeseen  requirements  that  must  be  met  before  the  PM  will  consider 
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transition.  Any  requirement  change  will  end  the  current  Compliance  effort.  Another  effort  may 
start  in  the  future,  once  the  new  or  modified  requirements  have  been  addressed. 

(U)  An  important  note  is  that  all  Compliance  Plan  steps  may  not  be  required  based  on  the 
PM’s  risk  tolerance.  If  the  PM  has  an  urgent  need,  he  could  accept  additional  risk  and  bypass 
some  steps  in  the  Compliance  Plan  process  on  his  way  to  transition.  This,  although  possible,  will 
more  than  likely  not  be  a  common  practice.  A  successful  Gate  5  review  implies  that  the  APS  has 
been  granted  a  TRL  6.  At  this  point  the  PM  has  the  option  to  transition  the  APS  into  a  program 
of  record.  By  no  means  does  achieving  a  TRL  6  or  APS  Compliance  guarantee  transition  onto  a 
platform;  final  transition  authority  lies  with  the  PM. 

(U)  Configuration  Management 

(U)  Each  Compliance  Plan  effort  is  tailored  to  a  specific  APS  hardware  and  software 
configuration.  At  the  beginning  of  the  effort,  TARDEC  and  the  PM  will  determine  applicable 
tasks  and  tests  for  each  TRL  milestone.  Once  the  TRL  assessment  process  has  started,  any 
configuration  or  design  change  will  require  a  new  Compliance  Plan  effort.  It  is  possible  to  have 
different  configurations — either  software  or  hardware — at  different  TRLs.  PMs  reserve  the  right 
to  transition  any  configuration  at  any  time,  depending  on  urgent  needs  and  their  risk  tolerance  for 
the  potential  capability. 

(U)  During  an  APS  assessment,  if  configuration  or  design  changes  are  deemed  necessary,  a  new 
Compliance  Plan  request  must  be  submitted.  For  example,  changes  in  the  processor  software 
may  affect  the  sensor  perfonnance;  as  a  result,  all  elements  of  the  Compliance  Plan  assessment 
must  be  reevaluated.  Any  requirement,  configuration  or  design  changes  results  in  the 
tennination  of  the  current  Compliance  effort.  During  the  subsequent  Compliance  Plan  efforts, 
elements  may  be  accepted  based  on  similarity  to  previous  configurations  or  designs,  but  those 
decisions  will  be  made  at  each  review  or  submission. 

(U)  Figure  5  shows  an  example  configuration  management  flowchart  for  an  APS  Compliance 
effort.  While  TARDEC  works  the  Compliance  effort  of  Configuration  C,  a  PM  could  transition 
or  start  a  program  of  record  for  either  Configuration  A  or  B,  depending  on  urgent  mission 
requirements  or  an  acceptable  perfonnance  risk  tolerance.  The  PM  acknowledges  that 
transitioning  an  earlier  configuration  may  have  degraded  safety  or  performance. 
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TRL  5 


TRL  6 


Config  A 


Config  A 


Requirement  or  Design  Change 


Similarity  / 

Config  B 

Config  B 

Similarity 


Requirement  or  Design  Change 


Config  C 


System 

Maturation 


Config  C 


Figure  5.  (U)  APS  Compliance  Plan  Configuration  Management 


(U)  Decision  Process 

(U)  An  example  of  an  APS  Compliance  Plan  decision  process  is  shown  in  Figure  6.  The 
decision  process  shows  example  tasks  and  how  the  TARGET  gate  review  described  above  fits 
into  the  APS  Compliance  Plan.  Each  gate  roughly  translates  to  a  TRL  threshold.  The  red  arrows 
show  the  effect  of  a  requirement,  configuration  or  design  change;  they  demonstrate  the  system 
maturation  process.  Theoretically,  each  subsequent  Compliance  Plan  effort  will  improve  upon 
the  previous  effort.  If  an  APS  has  a  successful  Gate  5  review,  it  reaches  a  major  decision  point. 
It  is  at  this  point  where  the  APS  is  assigned  the  appropriate  TRL  for  the  effort  and  granted 
compliance  (Typically  targets  6).  If  an  APS  completes  the  Compliance  Plan,  it  is  not  guaranteed 
that  it  will  be  granted  compliance  status  or  transition  to  a  program  of  record. 
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Configuration,  Design  or  Requirements  Change 


Figure  6.  (U)  APS  Compliance  Plan  Decision  Process 

(U)  The  APS  Compliance  Plan  concentrates  primarily  on  verifying  TRL  4  through  6  tests. 
Prior  to  attaining  TRL  4  (Gate  3  review)  the  design  intent  is  taken  into  account.  Similarly, 
before  reaching  TRL  5  (Gate  4  review)  all  necessary  component-level  testing  in  a  relevant 
environment  as  well  as  SIL  unit  testing  must  be  successfully  completed.  At  the  TRL  6  milestone 
(Gate  5  review)  the  system  should  have  a  successful  prototype  demonstration  in  a  relevant 
environment  and  successful  completion  of  SIL  integration  testing.  At  this  point,  the  system 
should  be  mature  enough  for  a  PM  to  transition  the  APS  onto  the  target  platform. 

(U)  During  the  early  conceptual  and  development  stages  it  is  essential  to  design  for  the 
relevant  environment  as  well  as  the  platform  and  Army  Fuze  Safety  Board  requirements.  If  a 
PM  needs  an  APS  that  will  work  in  extreme  weather  conditions  of  -40  to  120°C  it  would  not 
make  sense  to  design  a  system  for  operating  in  the  temperature  range  of  -10°  to  100°C.  Not 
meeting  the  platform  requirements  is  an  easy  non-starter  for  PMs.  Similarly,  the  APS  must  be 
Fuze  Board  compliant  prior  to  transition  onto  a  platform.  Understanding  the  Fuze  Board 
requirements  and  designing  to  them  at  an  early  conceptual  stage  can  make  a  big  difference  for  an 
APS  looking  for  transition.  PM  support  is  required  for  a  letter  of  compliance,  and  if  its  support  is 
not  given  for  a  particular  compliance  plan,  the  assessment  will  be  made  with  existing  guidelines 
and  given  a  higher  risk  potential. 

(U)  The  APS  Compliance  Plan  crawl,  walk,  run  strategy  is  shown  in  Table  1.  The  table 
provides  a  visual  representation  of  how  each  TRL  builds  on  the  previous  TRL.  TRL  4  primarily 
deals  with  design  intent  and  early  stage  conceptual  and  developmental  testing.  At  the  next  level, 
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individual  components  should  be  designed  and  SIL  validation  and  verification  begins.  Once 
each  component  has  been  successfully  tested  in  the  relevant  environment,  APS  system 
integration,  system  level  testing  and  prototype  demonstration  can  begin. 


Table  1.  (U)  APS  Compliance  Plan  Crawl,  Walk,  Run  Strategy 


GATE  3 / TRL  4 

GATE  4 / TRL  5 

GATE  5 / TRL  6 

Design  Intent 

Component-Level 

System-Level 

Relevant  Environment 

Component  Analysis 

Full  System  Demonstration 

Platfonn  Requirements 

Test  Plan  Outlines 

Integration  on  Platform 

Fuze  Board  Compliance 

Component  Testing  in 
Relevant  Environment 

Operations  &  Support  Plan 
with  Projected  Costs 

Production  Readiness 

SIL  Validation 

Prototype  Cost  Estimates 

UNCLASSIFIED 


(U)  At  any  point  if  the  Compliance  Plan  effort  fails  to  meet  a  requirement  or  changes  to  the 
design  or  configuration  (software  or  hardware)  are  needed,  the  assessment  is  ended.  Once  the 
necessary  changes  have  been  addressed,  another  assessment  based  on  the  revised  configuration 
may  be  undertaken,  if  the  resources  and  support  required  are  available.  Certain  component  tests 
may  still  be  considered  acceptable  based  upon  similarity  to  previous  configurations  or  designs,  if 
deemed  appropriate  by  TARDEC.  However,  each  component  will  be  readdressed. 

(U)  Together  the  Compliance  Plan  assessments  for  an  APS  will  go  through  a  system 
maturation  or  optimization  process.  Each  effort  could  find  minor  design  flaws  or  software  bugs 
that  require  a  redesign  of  the  system  or  a  component.  An  advantage  of  the  Compliance  Plan  is 
that  these  minor  issues  and  bugs  can  be  found  early  in  the  development  process  when  the 
monetary  cost  of  redesigning  components  or  software  is  significantly  lower  that  when  the  APS  is 
farther  along  in  the  process.  Each  time  these  minor  issues  are  fixed,  the  risk  of  failures  if 
transitioned  onto  a  platform  is  considerably  decreased. 

(U)  A  major  decision  point  occurs  after  the  APS  successfully  reaches  the  Gate  5  review.  It  is 
at  this  point  that  TARDEC  must  determine  the  appropriate  TRL  of  the  system  and  recommend  it 
for  compliance.  Depending  on  which  tests  have  been  completed  successfully,  TARDEC  also 
assesses  if  there  is  a  significant  risk  if  the  PM  opts  to  transition  the  APS.  It  is  possible  for 
TARDEC  to  determine  that  the  risk  is  too  high,  implying  the  APS  may  not  reach  its  objective 
TRL  Compliance.  Similarly,  if  the  APS  reaches  TRL  6,  it  is  not  guaranteed  transition  to  a 
program  of  record.  This  decision  is  ultimately  left  to  the  PM;  however  receiving  TARDEC 
compliance  will  increase  the  chance  of  being  selected  for  transition  onto  a  platfonn. 

(U)  SIL  Validation 

(U)  While  completing  a  Compliance  Plan  effort,  TARDEC  plans  to  perfonn  in-house  SIL 
validation  testing  on  the  APS  and  the  individual  components.  SIL  validation  is  a  disciplined 
process  to  evaluate  the  behavior,  performance  and  robustness  of  both  a  system  and  its 
components.  The  expected  behavior,  performance  and  robustness  of  the  system  and  components 
should  be  formally  described  and  measured  prior  to  the  validation  process.  This  would  include 
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factors  such  as  functionality,  logical  correctness  of  the  component/system  and  timing  constraints. 
More  specifically,  TARDEC  will  detennine  if  the  APS  functions,  if  it  operates  as  expected  and  if 
it  operates  fast  enough. 

(U)  Validation  of  a  component  or  system  will: 

(1)  detennine  that  the  engineering  design  and  development  process  is  complete  and 
meets  specifications; 

(2)  minimize  design  risks; 

(3)  detennine  if  the  design  is  supportable,  practical  and  maintainable; 

(4)  evaluate  tradeoffs  against  specification  requirements. 

(U)  Detailed  reports  of  observation  will  be  recorded  for  each  stage  of  SIL  testing.  These  will 
help  detennine  the  test’s  pass  and  failure  metrics.  A  failure  may  be  due  to  a  nonconformance  to 
the  requirements;  there  has  been  an  enor  in  conducting  the  test  (resulting  in  a  ‘no-test’);  or  that 
the  implementation  cannot  be  executed.  The  TARDEC  SIL  validation  process  will  be  used  to 
validate  both  software  and  hardware  components  prior  to  the  system  as  a  whole.  Specifically, 
TARDEC  will  concentrate  on  SIL  unit  testing,  SIL  integration  testing  and  SIL  validation  testing. 

(U)  SIL  unit  testing  is  the  verification  and  validation  method  used  to  exercise  the  features  of 
individual  components  when  they  are  isolated  from  other  components  of  the  system.  The  first 
step  of  unit  testing  is  to  define  the  individual  test  cases  or  components.  A  detailed  breakdown  of 
the  APS  is  required  to  detennine  what  parts  of  the  system  are  considered  individual  components. 
Components  are  defined  as  a  piece  of  application  that  has  its  own  thread  of  control. 

(U)  There  are  two  general  approaches  to  accomplish  SIL  unit  testing.  The  first  of  which  is  to 
apply  all  possible  use  cases  as  found  in  the  requirements.  This  is  typically  difficult,  if  not 
impossible,  to  accomplish  on  a  complex  APS.  The  second  approach  is  to  apply  a  large  range  of 
data  variation  for  function  parameter  value;  this  is  less  robust  than  the  first  method,  but  is 
significantly  more  reasonable. 

(U)  In  order  to  successfully  accomplish  SIL  unit  testing,  the  test  engineer  must  be  familiar 
with  the  content  of  the  unit  being  tested.  Finding  and  eliminated  bugs  at  the  component  level 
will  prevent  difficult  tracking  of  trivial  errors  in  the  complex  system  level  testing  that  occurs 
later  in  the  SIL  validation  process.  The  higher  the  level  of  testing,  typically  the  more  difficult  it 
is  to  isolate  individual  bugs.  The  goal  is  to  find  as  many  bugs  as  possible  during  SIL  unit  testing, 
to  make  the  integration  and  system  level  validation  testing  easier. 

(U)  SIL  unit  testing  can  be  broken  into  two  general  categories:  functional  tests  and 
requirements  verification.  In  a  functional  test,  the  test  engineer  is  concentrating  on  whether  the 
components  function  at  all.  Here,  the  goal  is  to  verify  that  the  component  is  stable,  does  not 
crash  unexpectedly  and  sends/receives  messages  in  the  appropriate  fonn.  Requirement  testing 
verifies  whether  the  component  meets  required  performance.  Here,  the  goal  is  to  verify  the 
logical  correctness  and  timing  constraints  of  the  component. 

(U)  SIL  integration  testing  evaluates  the  functionality  of  a  collection  of  integrated 
components;  validation  of  the  system  as  a  whole.  The  system  at  this  point  is  examined  by  a 
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stand-alone  system  and  is  not  connected  to  the  ‘outside  world’  that  is  environmental  conditions, 
etc.  Tests  are  similar  to  that  of  unit  testing,  except  at  a  slightly  higher  level.  Again,  the 
functionality  and  requirements  categories  of  testing  will  be  used. 

(U)  SIL  validation  and  system  testing,  also  referred  to  as  Hardware-in-the-Loop  (HWIL) 
testing,  is  the  equivalent  of  a  high  level  integration  test.  Components  have  been  integrated  into  a 
system  and  tested  at  the  previous  stage.  At  this  point  the  system  is  connected  to  the  ‘outside 
world’  to  evaluate  function  and  perfonnance.  An  added  advantage  to  performing  SIL  validation 
testing  in  a  lab  environment  as  opposed  to  field  testing  is  the  monetary  and  potential  schedule 
savings. 

(U)  Future  Plans 

(U)  The  APS  Compliance  Plan  will  utilize  the  TARDEC  Advanced  Collaborative 
Environment  (ACE)  for  all  future  Compliance  Plan  efforts.  Users  will  have  access  to  any 
applicable  reference  documents,  current  APS  requirements  as  well  as  an  up-to-date  version  of  the 
tasks  and  tests  required  for  each  TRL  milestone.  Each  contractor  will  have  their  own  folder  that 
will  organize  all  Compliance  Plan  documents  by  configuration.  The  most  recent  version  of  the 
plan  is  provided  in  Appendix  A. 

(U)  Summary 

(U)  The  TARDEC  Active  Protection  System  (APS)  Compliance  Plan  attempts  to  bridge  the 
gap  between  APS  development  and  integration  onto  a  platform.  It  is  intended  to  serve  as  a 
common  standard  for  all  APS  developers  to  follow  as  a  template.  A  Compliance  Plan  effort 
should  help  the  contractors  design  the  APS  with  the  system  requirements  and  the  relevant 
environment  in  mind.  This  will  help  decrease  performance  and  safety  risks  while  increasing  the 
possibility  of  transition  by  a  Program  Manager  (PM). 

(U)  Each  Compliance  Plan  effort  will  be  subject  to  configuration  management  to  encourage 
system  maturation  and  focused  development  of  the  system.  This  will  increase  the  possibility  of 
reaching  a  higher  TRL  milestone  and  better  prepare  the  system  for  transition.  All  steps  in  the 
Compliance  process  are  not  mandatory;  the  PM  has  final  decision  authority  of  which  steps  need 
to  be  completed.  At  any  point  during  the  Compliance  effort,  the  PM  may  transition  any 
configuration  (hardware  or  software)  depending  on  urgent  mission  requirements  of  acceptable 
performance  risk  limits. 

(U)  Upon  completion  of  an  APS  Compliance  effort,  the  system  is  not  guaranteed  compliance 
status  or  transition  into  a  program  of  record.  Successful  completion  will  not  guarantee  transition, 
although  it  may  increase  the  possibility  of  transition.  The  PM  has  final  decision  authority  of 
which  configuration  to  transition  and  when  it  will  be  transitioned  onto  a  platform. 

(U)  For  APS  Compliance  Plan  questions,  comments,  additional  information  or  instructions 
for  how  to  access  the  APS  Compliance  Plan  on  ACE  please  contact: 
D  AMIT  ARDECGS  SAP .  C@conus  .army  .mil . 
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APPENDIX  A 

TARDEC  APS  COMPLIANCE  PLAN 
VERSION  2.0 

Last  Updated:  16  AUG  2010 


Line 

Task  Name 

TRL  * 

1 

Gate  1 

* 

2 

Concept  and  Performance 

3 

Proof  of  Concept  Demonstration 

TRL  3 

4 

Preliminary  SWAP-C 

TRL  3 

5 

Preliminary  Performance  (P  defeat) 

TRL  3 

6 

Verified  Model 

TRL  3 

7 

Timeline  Analysis 

TRL  3 

8 

Assumed  User  Requirements 

TRL  3 

9 

SRR  w/  Vendor 

TRL  3 

10 

Functional  Baseline  (System) 

TRL  3 

11 

Allocated  Baseline  (Item) 

TRL  3 

12 

Product  Baseline  (Component) 

TRL  3 

13 

RFI  Applicable  Documents 

TRL  3 

14 

Equipment  Parts  list  (EPL)  /  Configuration  Parts  List  (EPL)  {Including  software  build} 

TRL  3 

15 

Bill  of  Materials  (BOM)  definition  breakdown  through  purchased  COTS  &  raw  material 

TRL  3 

16 

Military  and  Federal  Specifications,  Standards,  and  handbooks  used. 

TRL  3 

17 

Interface  Control  Documentation.  This  includes  all  related  of  referenced  Interface 
control  documents  and  interface  control  specifications. 

TRL  3 

18 

Other  Documentation 

19 

Establish  Current  TRL  of  the  APS 

20 

IPR  w/  vendor  and  PM 

21 

Assign  TARDEC  Sponsored  APS  Build  No. 

22 

Gate  2 

* 

23 

System  Design 

TRL  3 

24 

Verify  Design  Intent  (Relevant  Environment) 

TRL  3 

25 

Verify  Design  Intent  (PM  Requirements) 

TRL  3 

26 

Functional  Prototype 

TRL  3 

27 

Technology  Platform  Plan 

TRL  3 

28 

Gate  3 

* 

29 

LRU  Functional  Block  Diagram 

TRL  4 

30 

LRU  Characteristics  and  Requirements 

31 

Full  Performance  Envelope  defined  (PO,  FA,  Arena  Testing,  Defeat  Mechanism,  etc.) 

TRL  4 

32 

Shake,  Rattle,  Roll,  Specialty  Analysis 

TRL  4 

33 

Architecture,  Requirements,  CM 

TRL  4 

i 
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34 

Insensitive  Munitions  Tests 

TRL  6 

35 

Insensitive  Munitions  Board  Approval  Letter 

TRL  6 

36 

Fast  cook-off 

TRL  6 

37 

Slow  cook-off 

TRL  6 

38 

Bullet  impact 

TRL  6 

39 

Fragment  impact 

TRL  6 

40 

Sympathetic  detonation 

TRL  6 

41 

Shaped  charge 

TRL  6 

42 

High  velocity  fragment  impact 

TRL  6 

43 

Counter  Measure 

44 

SMALL  ARMS  Protection  (7.62  Ball) 

TRL  5 

45 

Environmental 

TRL  5 

46 

Temperature  Envelope 

TRL  5 

47 

Temperature  Cycling 

TRL  5 

48 

Sand 

TRL  5 

49 

Humidity 

TRL  5 

50 

Salt  Spray 

TRL  5 

51 

Vibration  MIL-STD  810 

TRL  5 

52 

Environmental  Tests 

TRL  5 

53 

Fly-Out  Counter  Measure 

54 

Countermeasure  Sensor  (seeker) 

TRL  5 

55 

Range 

TRL  5 

56 

Timing 

TRL  5 

57 

Accuracy 

TRL  5 

58 

Airframe  (SE) 

59 

Safety  factors  and  structural  guidance  as  specified  in  MIL-M-8856B  used  for  guidance 
in  developing  the  airframe. 

60 

Netting  analysis  to  verify  motor  case  structural  design. 

61 

Finite  element  structural  analyses  to  verify  airframe  integrity  for  flight  testing. 

62 

Modal  analyses  to  determine  mode  shapes  and  frequencies.  Results  used  to  develop 
body  bending  transfer  functions  for  design  of  autopilot.  Modal  frequencies  correlated 
with  telemetry  data  from  flight  testing. 

63 

Aero-elastic  flutter  analyses  to  determine  flutter  boundaries  of  airfoil  surfaces  used  for 
flight  stabilization. 

64 

Hydro-burst  tests  of  motor  case  to  insure  structural  integrity. 

65 

All  airframe  motor  cases  hydro-proofed  prior  to  use  in  flight  testing. 

66 

Static  motor  firings  to  characterize  motor  performance,  including  thrust  and  pressure 
loads  acting  upon  airframe. 

TRL  4 

67 

Successful  flight  of  airframe  on  LTV  flights. 

TRL  5 

68 

Successful  flight  of  airframe  on  BTV  flights. 

TRL  6 

69 

Successful  flight  of  airframe  on  CTV  flights. 

TRL  6 

ii 
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70 

Propulsion 

71 

Warhead 

72 

IMU 

73 

Inertial  laboratory 

74 

Characterization  tests  confirm  IMU  performance  compliance  over  temperature  from 
+60  deg  C  to  -40  deg  C.  Components  of  a  characterization  test  are: 

TRL  6 

75 

-  static  noise  (gyro  angle  random  walk  and  accelerometer  velocity  random  walk) 

TRL  6 

76 

-  tumble  (accelerometer  and  gyro  bias  &  repeatability,  misalignments,  and 
accelerometer  scale  factor) 

TRL  6 

77 

-  integrated  angle  (gyro  scale  factor) 

TRL  6 

78 

-  rate  (gyro  scale  factor  linearity) 

TRL  6 

79 

High-g  centrifuge  testing  provides  accelerometer  linearity  verification  up  to  200g. 

TRL  6 

80 

Vibration  testing  provides  measures  of  vibration  rectification  error  (VRE). 

TRL  6 

81 

IMU  performance  is  measured  against  the  HG1730  Critical  Item  Specification, 

Document  #  DS35323-01,  dated  2007-12-17. 

TRL  6 

82 

System  Integration  Facility  (SIF) 

TRL  6 

83 

SIF  testing  ensures  that  IMU  interface  functionality  is  maintained  as  the  interceptor 
components  are  assembled. 

TRL  6 

84 

SIF  testing  is  top-level  and  provides  only  a  general  check  that  the  IMU  is  operational, 
usually  via  direction  cosine  matrix  (DCM)  checks  in  several  orientations. 

TRL  6 

85 

Hardware-in-the-Loop  (HWIL) 

TRL  6 

86 

HWIL  tests  are  used  to  confirm  that  the  IMU  mounting  orientation  is  correct  by 
inspection  of  IMU  DCM  values,  and  magnitudes  and  signs  of  IMU-reported  rates  about 
each  missile  body  axis  relative  to  the  applied  rates. 

TRL  6 

87 

Flight  Tests 

88 

Fire  Control 

89 

Deployment 

TRL  5 

90 

Slew  Rate 

TRL  5 

91 

Elevation  Rate 

TRL  5 

92 

Warm  up 

TRL  5 

93 

BIT 

TRL  5 

94 

Self  Calibration 

TRL  5 

95 

Launch  Controller 

TRL  5 

96 

Warhead 

TRL  5 

97 

IMU 

TRL  5 

98 

Fire  control 

TRL  5 

99 

Eject  (SE) 

TRL  5 

100 

Vertical  Launch  Architecture 

TRL  5 

101 

Eject  Gas  Generator  (EGG) 

TRL  5 

iii 
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102 

Pop-Up  /  Pitch-Over  (PUPO) 

TRL  5 

103 

POMs  (Pitch-Over  Motors) 

TRL  5 

104 

Command  and  Control  Processor 

TRL  5 

105 

Fuze  Board  Approval  Letter 

TRL  5 

106 

Memory  Requirements  (ROM) 

TRL  5 

107 

Conforming  Electrical  Components 

TRL  5 

108 

Software  Requirements 

TRL  5 

109 

Environmental 

TRL  5 

110 

Temperature  Envelope 

TRL  5 

111 

Temperature  Cycling 

TRL  5 

112 

Vibration  MIL-STD-810 

TRL  5 

113 

Temperature  Limits  (SE) 

TRL  5 

114 

Noise  Factors  (SE) 

TRL  5 

115 

Anticipated  environmental  limits/qualifications  for  each  LRU  (SE) 

TRL  5 

116 

Lightning  strike  requirements  (SE) 

TRL  5 

117 

Convoy  limitations  (with  the  same  APS  systems  installed)  (SE) 

TRL  5 

118 

EMI/EMC  Requirements 

TRL  5 

119 

SIL  Processor  Validation  Testing 

TRL  6 

120 

Environmental  Tests 

TRL  6 

121 

Search  Sensor 

122 

EMI/EMC 

TRL  5 

123 

Clutter 

TRL  5 

124 

FOV 

TRL  5 

125 

Resolution 

TRL  5 

126 

Update  Rate 

TRL  5 

127 

False  Alarm  Rate 

TRL  5 

128 

Optical 

TRL  5 

129 

Sensor  Architecture 

TRL  5 

130 

Vibration  (Microphonics,  etc.)  (SE) 

TRL  5 

131 

Tracking  Sensor 

132 

EMI/EMC 

TRL  5 

133 

Clutter 

TRL  5 

134 

FOV 

TRL  5 

135 

Resolution 

TRL  5 

136 

Update  Rate 

TRL  5 

137 

False  Alarm  Rate 

TRL  5 

138 

Optical 

TRL  5 

139 

Sensor  Architecture 

TRL  5 

140 

Vibration  (Microphonics,  etc.)  (SE) 

TRL  5 

141 

Sensor  Validation  Testing 

TRL  6 

142 

Environmental  Tests 

TRL  6 

iv 

UNCLASSIFIED 


UNCLASSIFIED 


143 

Software 

144 

Software  Development  Plan 

TRL  5 

145 

Information  Assurance  Risks  are  identified 

TRL  4 

146 

Metrics  that  will  be  used  during  software  development  are  defined  (ex.  SLOC,  Function 
Points,  Requirements  Volatility,  ...) 

TRL  4 

147 

Requirements  are  configuration  managed  (through  formal  CM  plan  at  TRL  5) 

TRL  4 

148 

Security  classification  of  all  system  data  is  documented. 

TRL  5 

149 

Software  Development  Metrics  are  being  collected 

TRL  5 

150 

Configuration  Management  plan  documented 

TRL  5 

151 

Configuration  Management  plan  followed 

TRL  5 

152 

The  developer's  processes  are  in  compliance  with  CMMI  Level  3  or  equivalent 

TRL  6 

153 

Draft  software  documentation  is  available  (Software  Requirements  Specification, 
Software  Design  Document,  ...) 

TRL  6 

154 

Developer  is  able  to  estimate  software  program  size  in  lines  of  code  and/or  function 
points 

TRL  4 

155 

Software  Development  metrics  are  sufficient  to  ensure  effective  process  management 

TRL  4 

156 

Software  issues  are  tracked 

TRL  5 

157 

Software  issues  are  configuration  managed 

TRL  5 

158 

Software  Quality  Assurance  program  is  documented 

TRL  5 

159 

Software  Quality  Assurance  program  is  actively  monitoring  software  development 

TRL  5 

160 

Interface  control  process  is  established 

TRL  6 

161 

Software  Development  Metrics  are  used  to  improve  process  and  /  or  product  quality 

TRL  6 

162 

Draft  preliminary  user  manual  is  available. 

TRL  6 

163 

Software  SIL  Requirements 

TRL  5 

164 

System  requirements  are  decomposed  to  allocate  appropriate  software  rqts 

TRL  4 

165 

HEMP  hardening  requirement  matches  target  vehicle  specification 

TRL  4 

166 

TEMPEST  requirements  are  identified 

TRL  4 

167 

EMI/EMC  requirements  are  identified 

TRL  4 

168 

Necessary  IA  Controls  have  been  identified. 

TRL  5 

169 

External  interface  requirements  are  documented  (source,  format,  structure,  content, 
and  method  of  support) 

TRL  5 

170 

System  requirements  are  documented. 

TRL  4 

171 

System  requirements  match  user  needs  in  general  terms 

TRL  4 

172 

Software  requirements  allocated  among  SW  modules  (requires  draft  SW  architecture) 

TRL  4 

173 

Performance  Requirements  for  target  hardware  have  been  identified  and  documented. 

TRL  4 

v 
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UNCLASSIFIED 


174 

Internal  interface  requirements  are  documented,  including  data  requirements  and 
formats 

TRL  5 

175 

Implementation.  Includes  software  design  and  coding. 

176 

High  level  System  Architecture  is  documented  which  includes  interfacing  systems. 

TRL  4 

177 

Software  Architecture  development  has  begun,  including  consideration  of 
interoperability,  reliability,  maintainability,  extensibility,  scalability,  and  security  issues 

TRL  4 

178 

Software  architecture  is  completed  and  documented 

TRL  5 

179 

Coding  of  individual  functions/modules  completed  for  initial  functionality. 

TRL  5 

180 

Target  processors  have  been  identified  and  are  readily  available  in  production 
quantities. 

TRL  6 

181 

Appropriate  IA  Controls  have  been  implemented  in  software. 

TRL  6 

182 

All  "high  severity"  software  issues  have  been  resolved.  "High  severity"  will  vary  with 
the  individual  issue  tracking  system,  but  generally  defined  as  "affects  mission  with  no 
work-around  available". 

TRL  6 

183 

Analysis  of  timing  constraints  completed 

TRL  6 

184 

Analysis  of  database  structures  and  interfaces  completed 

TRL  6 

185 

Demonstration  and  Validation.  Includes  all  SIL  activities. 

186 

Individual  functions  or  modules  demonstrated  in  a  laboratory  environment  (interfaces 
are  emulated/simulated) 

TRL  4 

187 

Some  ad  hoc  integration  of  functions  or  modules  demonstrates  that  they  will  work 
together 

TRL  4 

188 

End-to-end  functionality  of  the  system  software  is  demonstrated  in  a  laboratory 
environment  (simulated  interfaces  to  external  systems).  APS  Example:  The  system 
receives  a  simulated  detection  from  a  sensor,  performs  necessary  processing,  and 
activates  a  simulated  countermeasure. 

TRL  5 

189 

Software  runs  on  processor(s)  with  characteristics  representative  of  target 
environment 

TRL  5 

190 

Representative  model/prototype  demonstrated  in  a  high-fidelity  lab  /  simulated 
operational  environment.  Includes  external  interfaces  to  fielded  systems. 

TRL  6 

191 

SIL  Validation  Testing 

192 

Stressing  Case  1  Complex  Attack 

TRL  6 

193 

Stressing  Case  2  Clutter 

TRL  6 

194 

Stressing  Case  3  Simultaneous  Attack 

TRL  6 

195 

Power  Supply 

196 

Environmental 

TRL  5 

197 

Temperature  Envelope 

TRL  5 

198 

Temperature  Cycling 

TRL  5 

199 

Vibration 

TRL  5 

200 

Safety  Board  Approval  Letter 

TRL  6 

201 

Memory  Requirements  (ROM) 

TRL  5 

202 

Conforming  Electrical  Components 

TRL  5 

vi 
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UNCLASSIFIED 


203 

Software  Requirements 

TRL  5 

204 

SMALL  ARMS  Protection  (7.62  Ball) 

TRL  5 

205 

Cyclic  Power  Testing 

TRL  5 

206 

Environmental  Tests 

TRL  6 

207 

CDA  /  Controller 

208 

Fuze  Board  Approval  Letter 

TRL  6 

209 

Memory  Requirements  (ROM) 

TRL  5 

210 

Adjustable  Illumination 

TRL  5 

211 

Conforming  Electrical  Components 

TRL  5 

212 

Environmental 

TRL  5 

213 

Temperature  Envelope 

TRL  5 

214 

Temperature  Cycling 

TRL  5 

215 

Vibration 

TRL  5 

216 

Environmental  Tests 

TRL  5 

217 

System  Demonstration 

218 

General  Test  Documentation 

TRL  4 

219 

Document  System  Configuration  (P/N,  S/N,  and  Software  Builds) 

TRL  5 

220 

Document  all  test  article  and  sensor  locations  and  orientations  (GPS) 

TRL  5 

221 

Document  environmental  conditions  (temp,  wind,  humidity). 

222 

Take  pictures  of  test  articles  and  test  setup 

223 

Examine  test  articles  for  damage,  physical  anomalies,  and/or  missing  parts  &  record 
observations 

224 

Test  series  will  be  tailored  for  vehicle  classes 

225 

Physical  Inspection  and  Measurement 

226 

Visual  Inspection 

227 

Size  and  Weight 

228 

Function  check-out 

229 

Emulated  Intercept  Tests  (Rocket-On-Wire  or  Inert  Threat) 

TRL  5 

230 

Single  Threat  Detection  and  Tracking 

TRL  5 

231 

Near  Simultaneous  Engagement  Multiple  Threats 

TRL  6 

232 

High  Angle  of  Attack 

TRL  6 

233 

Edge  of  Coverage  Envelope 

TRL  6 

234 

Threat  Discrimination  (7.62mm/40mm  Inbound) 

TRL  5 

235 

Threat  Discrimination  (7.62mm/40mm  Outbound) 

TRL  5 

236 

Live  Threat  Intercept  Tests  -  Stationary  Platform 

TRL  6 

237 

Single  Threat  Engagement 

TRL  6 

238 

Near  Simultaneous  Engagement  Multiple  Threats 

TRL  6 

239 

High  Angle  of  Attack 

TRL  6 

240 

Collateral  Hazard  Characterization  Tests 

TRL  6 

241 

Data  for  hazard  analysis  collected  during  other  tests 

TRL  6 

242 

Reliability  Testing 

TRL  5 

vii 

UNCLASSIFIED 


UNCLASSIFIED 


243 

TARDEC  Validation  Testing 

TRL  6 

244 

Functional  Interface  Parameters 

245 

Electronic 

246 

Signal  Characteristics 

TRL  5 

247 

Wave  Forms 

TRL  5 

248 

Voltage 

TRL  5 

249 

Frequencies 

TRL  5 

250 

Shielding  Requirements 

TRL  5 

251 

Circuit  impedance 

TRL  5 

252 

Current  Limits  /  requirements 

TRL  5 

253 

ELECTRICAL 

254 

power  requirements 

TRL  5 

255 

Temperature  Envelope  (SE) 

TRL  5 

256 

Frequency  characteristics 

TRL  5 

257 

Temperature  Cycling  (SE) 

TRL  5 

258 

Voltage  levels 

TRL  5 

259 

Sand  (SE) 

TRL  5 

260 

Power  ratings 

TRL  5 

261 

Humidity  (SE) 

TRL  5 

262 

Wave  forms 

TRL  5 

263 

Salt  Spray  (SE) 

TRL  5 

264 

Vibration  MIL-STD  810  (SE) 

TRL  5 

265 

Environmental  Tests  (SE) 

TRL  5 

266 

Grounding  requirements 

TRL  5 

267 

HYDRAULIC  AND  PNEUMATIC 

268 

Flow  rates 

TRL  5 

269 

Fluid  temperatures 

TRL  5 

270 

Pressure  requirements 

TRL  5 

271 

Power  requirements/source 

TRL  5 

272 

OPTICAL/ELECTRO-OPTICAL  REQUIREMENTS 

TRL  5 

273 

HUMAN  FACTORS/ENGINEERING 

TRL  6 

274 

Integration  Requirements 

275 

Interface  identification  and  description 

TRL  5 

276 

Functional  interface  specification  details  by  parameter 

TRL  5 

277 

Physical  interface  specification  details  by  parameter 

TRL  5 

278 

Environmental  parameter  details 

TRL  5 

279 

PHYSICAL  INTERFACE  PARAMETERS 

280 

Materials  specifications  (including  dissimilar  material  requirements). 

TRL  5 

281 

Dimensions  and  tolerances  of  mating  surface  (flanges,  bolt  holes,  mounting  plates, 
etc.,  with  applicable  sizes,  shapes,  and  spacing). 

TRL  5 

282 

Weight,  balance,  and  center  of  gravity. 

TRL  5 

viii 
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UNCLASSIFIED 


283 

Cabling  requirements  (connectors,  routing,  etc). 

TRL  5 

284 

Applied  loads. 

TRL  5 

285 

Accessibility  (installation  and  removal  clearance). 

TRL  5 

286 

Sealing  requirements,  leakage  prevention  and  detection. 

TRL  4 

287 

Pass  Through;  Formula's  guiding  the  number  of  and  sizes  (cross  sectional  cable  area)  of 
vehicle  access  holes  from  the  vehicle  cabin  to  the  exterior  required 

TRL  5 

288 

Anticipated  weight  per  unit  length  of  LRU  cable 

TRL  5 

289 

LRU  component  hardening  and  anticipated  vulnerabilities 

TRL  5 

290 

Verification  of  ENVIRONMENTAL  AND  SAFETY  PARAMETERS 

291 

Electromagnetic  interfaces,  compatibility  requirements 

TRL  5 

292 

Vibration  envelopes 

TRL  5 

293 

Shock  limits 

TRL  5 

294 

Acceleration  limits 

TRL  5 

295 

Temperature  limits 

TRL  5 

296 

Noise  factors 

TRL  5 

297 

Anticipated  environmental  limits/qualifications  for  each  LRU 

TRL  5 

298 

Lightning  strike  requirements 

TRL  5 

299 

Convoy  limitations  (with  the  same  APS  systems  installed) 

TRL  5 

300 

Gate  4 

* 

301 

Vehicle  Demonstrator 

302 

Vehicle  Integration 

303 

System  Definition 

304 

Preliminary  Design 

305 

A  and  B  kit  Configuration  Management 

306 

EMI /EMC  with  GFE 

307 

Fabricate  and  install  A  kit 

308 

Install  APS 

309 

System  Integration  and  Test 

310 

System  Validation  and  Test 

311 

Arena  Test 

312 

EMI/EMC  Tests 

313 

Vehicle  Durability  (RAM) 

314 

RAM/Durability  Tests 

315 

Performance  Testing 

316 

Sensor  FOV  Validation 

317 

Safety  Interlocks 

318 

Sensor  OTM  Performance  Validation  (Clutter,  pitch,  yaw  etc) 

319 

Software  Validation  (Vehicle  Coordinates,  safety  lock  outs  etc) 

ix 

UNCLASSIFIED 


UNCLASSIFIED 


320 

SIL  Validation 

321 

Mobility  Analysis 

322 

AP  limitation  on  Vehicle  Operation 

323 

Maintenance  /  Reloading 

324 

Reload  Test  with  Time  Analysis  and  tools  required. 

325 

Danger  Zone  Assessment 

326 

Test 

327 

Radar  Safety  Assessment 

328 

Test 

329 

Fratricide 

330 

Test 

331 

Convoy  Operations  /  limitations  (Jamming  etc)  Analysis 

332 

Safety  Certification  Release  /  Vehicle 

333 

Integrated  Performance 

334 

Live  Threat  Intercept  Tests  -  Moving  Platform 

335 

Single  Threat  Engagement 

336 

VEHICLE  CONFIGURATION  SOFTWARE  VALIDATION 

337 

Sensor  OTM  Performance  Validation  (Clutter,  pitch,  yaw  etc) 

338 

Software  Validation  (Vehicle  Coordinates,  safety  lock  outs  etc) 

339 

SIL  Validation 

340 

SIL  "Components"  integrated  work  together,  messages  transmitting,  protocols 
established,  scenarios  running 

TRL  4 

341 

SIL-  Concept  System  Analysis  complete  Preliminary  SWAP-C 

TRL  4 

342 

SIL-  Concept  System  Analysis  complete:  Analytical  Model  developed;  works  in 
conjunction  with  SIL.  Performance  Data,  SRL. 

TRL  4 

343 

System  Safety  and  Integration  Parameters 

344 

Description  of  powered  system  modes 

TRL  4 

345 

Maintenance  considerations 

TRL  4 

346 

Safety  lockout  considerations 

TRL  4 

347 

Radius  of  potential  injury  for  surrounding  personnel  (include  the  anticipated  injury 
severity). 

TRL  5 

348 

Operations  &  Support  /  Logistic  Plan 

349 

LRU  Component  Maintenance  Requirements  and  Interval 

TRL  6 

350 

LRU  Anticipated  shelf  /  useful  shelf  life 

TRL  6 

351 

Shipping  requirements 

TRL  5 

352 

Packaging  and  Shipping  instructions 

TRL  6 

353 

Shipping  Container  Description 

TRL  5 

354 

Reload  Procedure 

355 

Remove  Misfire  CMT 

356 

Define  CMT  disposal  method 

357 

Maintenance  Plan 

TRL  6 

x 
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358 

Develop  Tech  Manual 

TRL  6 

359 

Develop  Maintenance  Tools 

TRL  6 

360 

Training 

TRL  6 

361 

Technical  Documentation  Release 

362 

Material  Release 

363 

Prototype  Demonstration  in  Relevant  Environment 

TRL  6 

364 

ROM  Cost  Parameters 

TRL  5 

365 

TRL6  Certified  with  high  chance  of  success 

366 

Engineering  Prototype  LRU  cost 

TRL  5 

367 

Gate  5 

* 

368 

Limited  Production  LRU  costs 

TRL  5 

369 

Full  Production  LRU  costs. 

TRL  6 

370 

371 

Quality  Assurance 

TRL  5 

xi 

UNCLASSIFIED 


